Detecting wasteful data collection

ABSTRACT

A method and system comprising a duplication identifier module to analyze data input information to automatically identify duplicate expected inputs associated with a process are shown. The system includes logical process model information defining a logically structured series of process activities and data input information representing a plurality of expected inputs associated with respective process activities, with each expected input being indicative of expected collection of a corresponding data element during execution of the associated process activity. Each duplicate expected input comprises one of the plurality of expected inputs for which there is at least one other expected input with respect to a common corresponding data element.

CROSS-REFERENCE TO RELATED APPLICATION

This patent application is a continuation of U.S. patent applicationSer. No. 13/158,038, filed Jun. 10, 2011, the specification of which isincorporated herein by reference.

TECHNICAL FIELD

The present application relates generally to the technical field ofmethods and systems for modeling, analyzing and managing processes. Anexample embodiment relates to methods and systems to performcomputer-assisted process modeling.

BACKGROUND

Process modeling in systems engineering and software engineering relatesgenerally to modeling or mapping a process or a number of processes inan enterprise. Such process modeling may facilitate analysis andimprovement of the process (for example, serving to facilitate theanalysis of a manufacturing process, a business process, or the like).

Process modeling may therefore be useful for process management. Aprocess model may comprise structured information not only about thesequence and relationship of respective activities constituting aprocess or processes, but may also define relationships of processactivities to other process elements or components, such as informationtechnology (IT) systems, human resources, and the like. In certainembodiments, a business process model may therefore be part of a largerencompassing enterprise model. The latter may facilitate enterpriseresource and/or business process analysis and management.

A process model may also be used to generate a graphical representationof process information. Visual modeling languages used to representprocesses include Business Process Modeling Notation (BPMN) and theEvent-driven Process Chain (EPC).

BRIEF DESCRIPTION OF THE DRAWINGS

Some embodiments are illustrated by way of example and not limitation inthe figures of the accompanying drawings in which:

FIG. 1 is a schematic block diagram of a process modeling system in theexample form of an enterprise model system interfaced with an enterprisesystem, in accordance with an example embodiment.

FIG. 2 is a schematic block diagram of process model application(s)forming part of the example process analysis system.

FIG. 3 is a schematic diagram of a data structure of process modelinformation, according to an example embodiment

FIG. 4 is a high-level schematic diagram of an example system fordetecting wasteful data collection in a process.

FIG. 5 is a high-level view of a value chain forming part of anenterprise model, according to an example embodiment.

FIG. 6 is a lower-level view of the example enterprise model of FIG. 5,diagrammatically showing functional decomposition of one of the elementsof the value chain.

FIG. 7 is another lower-level view of the enterprise model of FIG. 5,diagrammatically illustrating the key processes in one of the functionsof FIG. 6.

FIG. 8 is diagrammatic view of an example of a process model, showing aseries of expected inputs associated with respective process activities.

FIG. 9 is a high-level flow chart of an example method of detectingwasteful data collection in a modeled process.

FIG. 10 is a schematic flow chart illustrating a method of detectingwasteful data collection, in accordance with an example embodiment.

FIG. 11 is a schematic flow chart illustrating a method of analyzingprocess model information, in accordance with an example embodiment.

FIG. 12 is a diagrammatic representation of a machine in the exampleform of a computer system within which a set of instructions for causingthe machine to perform any one or more of the methodologies discussedherein may be executed.

DETAILED DESCRIPTION

Example methods and systems to generate a process model or enterprisemodel and to perform automated analysis of the process model aredescribed. In the following description, for purposes of explanation,numerous specific details are set forth in order to provide a thoroughunderstanding of example embodiments. It will be evident, however, toone skilled in the art that other embodiments may be practiced withoutthese specific details.

According to an example embodiment, there is provided a system andmethod to generate a process model that includes logical process modelinformation and associated data input information with respect toexpected inputs associated with respective process activities of aprocess. There is also provided a system and method to perform analysis,using one or more processors, of process model information to processdata collection efficiency of a process represented by the processmodel.

The process model information may comprise, at least: a logical processmodel defining a plurality of activities forming part of the process,with the logical process model specifying relationships between therespective activities; and data input information regarding expectedinputs associated with process activities. The process model informationmay further comprise: IT system dependency information indicative ofdependency of respective activities on associated IT system elements,with the IT system dependency information including datastore dependencyinformation indicative of one or more datastores which may be accessedin execution of respective activities; and data dependency informationindicative of the dependency of process activities on data in the one ormore datastores which may be accessed in execution of respectiveactivities.

The term “process” as used herein comprises a series of activities toproduce a product or perform a service, and is to be interpreted broadlyas including a process group, a sub-process, or any collection ofprocesses. Therefore, the totality of activities and/or processes whichmay be performed in an enterprise may also be referred to as a process.In instances where the process model information is therefore withrespect to an enterprise, such as a business enterprise, the processmodel information may thus be in the form of an enterprise model.

The term “data” as used herein refers to any information items that aprocess may depend upon or utilize and is to be interpreted broadly asincluding master data, reference data, transaction data, event data,analytical data, meta-data, text or binary content, and the like.

Differently defined, the process model information may be in the form ofthe logical process model together with operationalization dataregarding various components utilized for operationalization of theprocess and on which process activities may be dependent. The logicalprocess model may include a sequence in which activities of the processare performed; rules determining subsequent activities to be performed;service-level agreements (SLAs); key performance indicators (KPIs); andthe like. The operationalization data may include human resource rolesfor performing respective activities; IT systems supporting respectiveactivities; data dependency information regarding respective activities;data input information indicating expected inputs, which may beassociated with particular process activities and/or processparticipants; physical infrastructure associated with respectiveactivities, such as vehicles, machinery, and the like; and otherelements associated with the process. In instances where the processmodel is in respect to a business enterprise, the resultant enterprisemodel may therefore depict, specify, or map the workings andinterrelationships of all elements that make up an enterprise.Enterprise elements or process elements modeled in such an enterprisemodel may include a value chain, business domains/sub-domains, businessfunctions/sub-functions, processes, activities, information/data, ITapplications, IT hardware, human resources, physical assets, and anyother elements relevant to the enterprise.

It is to be appreciated that the term “logical process model” refers tothe depiction, specification, or mapping of a series of activities of anassociated process, excluding process operationalization elements (e.g.,IT system components, human resource information, and data inputinformation).

“Process element” means any element of the process model, including IThardware, IT applications, human resource components, datastores,physical elements, events, and the like.

The data input information may comprise information regarding thecollection of data during performance of the process. The data inputinformation may therefore include a plurality of expected inputs, eachexpected input being associated with one of the process activities. Eachexpected input may indicate a particular data element or data item whichis to be inputted or collected during performance of an associatedprocess activity. The data input information may further include asource type identifier associated with each expected input, to identifya type of source from which the relevant data element is received. Thedata input information may yet further include, with reference to eachexpected input, a duplication acceptance indicator to indicate whetheror not a process designer or editor accepted duplication of inputs withrespect to the associated data element, and/or a duplication reasonindicator to indicate a reason provided by the process designer oreditor for input duplication. The terms “duplicate expected input” or“repetitive expected input” as used herein refers to an expected inputfor which there is at least one other expected input with respect to acommon corresponding data element within a particular process or partthereof. The data input information may include forms for collecting aplurality of data elements, the forms optionally being linked to orassociated with respective process activities.

The system may further include data state information indicative of thequality and/or availability of data in one or more datastores, which maybe accessed in execution of respective activities. The data stateinformation may include data quality information indicative of the dataquality of data in at least one datastore forming part of the processsystem. The data quality information may include data aging information,data validity, data accuracy, data completeness, data consistency, dataintegrity information, or the like.

It is to be appreciated that the data input information is distinct andseparate from, on the one hand, data dependency information, and, on theother hand, data state information. The data state information is withrespect to the state and/or quality of data in the process duringoperation, while the data dependency information is with respect to thedependency of process activities on particular data elements and/or datastores for performance of those process activities. In contrast, thedata input information provides a design-time indication of thecollection of particular data elements by respective processelements/participants.

The system may include a duplication identifier module to automaticallyidentify duplicated expected inputs and an alert generator to generate aduplication alert in response to identification of expected inputduplication. The system may further include an efficiency calculationmodule to calculate a data collection efficiency value based at least inpart on the identified duplicate expected inputs.

Another aspect provides a method comprising:

associating a plurality of expected inputs with respective processactivities of a logical process model comprising a logically structuredseries of process activities in a process, each expected input beingindicative of collection of a corresponding data element duringexecution of the associated process activity; and

using one or more processors, analyzing the plurality of expected inputsto calculate a data collection efficiency value with respect to thelogical process model, the data collection efficiency value beingcalculated based at least in part on the identification of repetitiveexpected inputs with respect to at least one data element

Yet another aspect may provide another method comprising:

storing in at least one database a plurality of expected input entriesindicative of respective data elements to be inputted into a processsystem in the execution of a process;

storing in association with each expected input entry informationillustrating one or more of a plurality of process activities duringwhich the corresponding data element is to be inputted; and

storing in association with at least one of the plurality of expectedinput entries a duplication reason indicator to indicate that repetitiveexpected input entries with respect to the corresponding data element isintentional.

Architecture

FIG. 1 is a network diagram depicting a client-server system 100, withinwhich one example embodiment may be deployed. A networked enterprisemodel system 102, in the example form of a dynamic process modelingsystem, provides server-side functionality, via a network 104 (e.g., theInternet, a Wide Area Network (WAN), or a Local Area Network (LAN), toone or more clients. FIG. 1 illustrates, for example, a web client 106(e.g., a browser, such as the Internet Explorer browser developed byMicrosoft Corporation of Redmond, Wash. State) and a programmatic client108 executing on respective client machines 110 and 112.

An Application Program Interface (API) server 114 and a web server 116are coupled to, and provide programmatic and web interfaces respectivelyto, one or more application servers 118. The application servers 118host one or more process model applications 120 (see FIG. 2). Theprocess model applications, in this example, are enterprise modelapplications. The application server(s) 118 are, in turn, shown to becoupled to one or more databases server(s) 124 that facilitate access toone or more database(s) 126.

The system 102 is also in communication with a process system whichsupports a process that is to be modeled by the process modelapplication(s) 120 (e.g., business process models (BPM)). In the exampleembodiment, the process system is a client enterprise system 140, whichsupports a business enterprise. The system 102 of the example embodimentof FIG. 1 is therefore an enterprise model system, while, in otherembodiments, similar or analogous systems may be process model systemsfor processes such as manufacturing processes, distribution processes,or the like. The process model application(s) 120 may be incommunication with components of an IT system of the enterprise, inparticular being in communication with a number of process servers 142,144 forming part of the IT infrastructure of the client enterprisesystem 140. Each of the process servers 142, 144 supports one or moreprocess applications 146, 148, with each process application 146, 148providing functionalities employed in the performance of an associatedactivity or process supported by the enterprise system 140. Each processserver 142, 144 may be in communication with one or more associateddatabase(s) or process datastore(s) 150, 152, to read and/or writeassociated process data to the respective process datastore(s) 150, 152.

For example, process application 146 may be an accounting application,with the process data in the associated process datastore(s) 150comprising client account information, while process server 144 may be acase management application, with the process data in the associatedprocess datastore(s) 152 comprising records of respective casesprocessed by the enterprise system 140. It will be appreciated that theenterprise system 140 may typically comprise a greater number of processservers 142, 144 and process datastores 150, 152 than are shown in FIG.1, but for ease of explanation FIG. 1 shows only two such processservers 142, 144. It is further to be appreciated that communication andinterfacing between respective process servers 142, 144 may occur viathe network 104, while some of the process servers 142, 144 may be indirect communication.

The process model application(s) 120 may provide a number of functionsand services to users that access the enterprise model system 102 (forexample, providing analytics, diagnostic, predictive and managementfunctionality relating to system architecture, processes, and theactivities of the enterprise supported by the enterprise system 140).Respective modules for providing these functionalities are discussed infurther detail with reference to FIG. 2 below. While all of thefunctional modules, and therefore all of the process modelapplication(s) 120, are shown in FIG. 1 to form part of the enterprisemodel system 102, it will be appreciated that, in alternativeembodiments, some of the functional modules or process modelapplications may form part of systems that are separate and distinctfrom the enterprise model system 102.

Further, while the system 100 shown in FIG. 1 employs a client-serverarchitecture, the example embodiments are, of course, not limited tosuch an architecture, and could equally well find application in adistributed, or peer-to-peer, architecture system, for example. Theprocess model application(s) 120 could also be implemented as standalonesoftware programs, which do not necessarily have networkingcapabilities.

The web client 106 accesses the process model application(s) 120 via theweb interface supported by the web server 116. Similarly, theprogrammatic client 108 accesses the various services and functionsprovided by the process model application(s) 120 via the programmaticinterface provided by the API server 114.

Process Model Application(s)

FIG. 2 is a block diagram illustrating multiple functional modules ofthe process model application(s) 120 of enterprise model system 102.Although the example modules are illustrated as forming part of a singleapplication, it will be appreciated that the modules may be provided bya plurality of applications. The modules of the application(s) 120 maybe hosted on dedicated or shared server machines (not shown) that arecommunicatively coupled to enable communications between servermachines. The modules themselves are communicatively coupled (e.g., viaappropriate interfaces) to each other and to various data sources, toallow information to be passed between the modules or to allow themodules to share and access common data. The modules of theapplication(s) 120 may furthermore access the one or more databases 126via the database servers 128.

The enterprise model enterprise model system 102 may therefore provide anumber of modules whereby a user may build or define a process model(s)or enterprise model for the enterprise system 140, monitor the executionof activities forming part of the process, and perform automateddiagnostic or predictive analysis of the process model. To this end, theapplication(s) 120 are shown to include at least one default processmodel module 216 to provide default process models. In instances wherethe process model is in respect to a business enterprise, the defaultprocess model module 216 may provide default BPMs, which are to serve asbases for a user to define a business process model specific to theenterprise system 140. The default BPMs may be predefined by a supplierof the business process model application(s) 120 and are in respect togeneric business processes relating to a variety of types of businessesor types of business activities. A user may thus, as a starting pointfor defining an enterprise-specific BPM, select one or more defaultprocess models which most closely approximate the business processesperformed by the enterprise system 140. The default process model module216 may typically provide default logical process models indicating aseries of activities, without specific operationalization informationindicating particular process elements or support elements on which theactivities are dependent.

A model building/editing module 204 is provided to enable a user oradministrator to define a specific process model, either by editing,adapting, or building on a selected default process model, or bybuilding a process model from scratch. The terms administrator, user,designer, and editor are used interchangeably herein to indicate aperson who performs design-time activities with respect to the processmodel. The model building/editing module 204 also enables the editing ofthe process model in response to changes in the process system 140 orthe associated processes. As mentioned above, such a process model mayrepresent sequences and relationships of business processes and businessprocess activities, as well as the relationships of such businessprocess activities to the IT infrastructure, process applications 146,148, expected inputs, and process data. An example enterprise model isdescribed in greater detail with reference to FIGS. 4-7 below.

As described above, the enterprise model system 102 may include logicalprocess model information together with data input information toindicate a plurality of expected data inputs. The logical process modelinformation may define a plurality of activities forming part of theprocess and may define the relationship between activities, such as thesequence in which activities are performed, and/or rules determiningchoices between respective activities. Dependency information definesprocess elements which contribute to performance of respective processactivities. The dependency information may include IT system dependencyinformation, which defines IT system elements, such as software andhardware components, contributing to respective activities. Thedependency information may further include human resource dependencyinformation, which defines particular human resources, people, orpersonnel contributing to respective activities. The dependencyinformation may also include, as part of the IT system dependencyinformation, datastore dependency information that indicates therelationship between respective activities and associated datastoresthat are accessed during execution of the respective activities.

The process model application(s) 120 further include a graphic userinterface (GUI) module 200 to generate and manage an interactive GUI todisplay various aspects of the process model and to permit usermanagement of the process model. In instances where all the processes ofthe enterprise system 140 are defined in a process model (e.g. instanceswhere the process model is an enterprise model), it is typically notpossible to display a representation of all of the processes and/or anentire business architecture in a single view, and the GUI will allowuser selection of different levels or layers of the enterprise model forviewing. Such drill-down functionality is described in greater detailbelow with reference to FIGS. 4-7.

A data input module 214 provides functionality to permit the input ofdata for use in process model analysis. Information about scheduleddowntime for the process applications 146, 148 and/or scheduled downtimefor IT infrastructure elements may, for example, be input via the datainput module 214. Similarly, in an example embodiment, human resourcescheduling information, such as information about personnel availability(e.g., holiday calendars) may also be input into the enterprise modelsystem 102. The data input module 214 may be configured for manual inputof this information, and may instead or in addition provide forautomatic integration of scheduling data from other databases. Forexample, personnel unavailability data may automatically be obtainedfrom a Human Resources database (not shown) forming part of theenterprise system 140.

A rules engine 202 may be provided to permit the definition of metricsby which the performance of business processes is to be measured. A usermay thus provide, via the rules engine 202, failure definitions thatspecify what constitutes failure of a particular business process. In anexample embodiment, the business process model may include SLAs whichspecify, in measurable terms, contractual service commitments describingthe minimum performance criteria an associated process is required tomeet. Failure to comply with the requirements of an SLA may be specifiedas constituting failure of the associated process. The rules engine 202may further enable the definition of performance indicators, such asKPIs, in relation to respective processes or process activities. Suchperformance indicators serve to provide quantifiable performancemeasurement of an associated process or process activity.

The model building/editing module 204 may include an input associationmodule 240 to effect user provision of expected inputs. The provision ofexpected inputs may comprise the association of particular data elementswith specified process activities. A user may thus specify that aparticular data element is to be received by a particular process entityin an associated process activity. The input association module 240 mayalso permit a user to input information regarding a type of source fromwhich the expected input is to be received. The system may furtherinclude a duplication identifier module 220 to identify duplicateexpected inputs in a particular process or part thereof. The duplicationidentifier module 220 may therefore be configured to identify when morethan one expected input with respect to a common data element isassociated with the process activities of the logical process model.

The process model application(s) 120 may further include an alertgenerator 242 to automatically generate a duplication alert in responseto the identification of expected input duplication by the duplicationidentifier module 220. The alert generator 242 may, for example, beconfigured to generate a duplication alert upon entry of an expectedinput by association of a particular data element with a processactivity, if that particular data element already forms part of anexpected input associated with another process activity. The alertgenerator may also be configured to prompt the user to accept or rejectthe identified duplicate expected input, and/or to provide a reason forthe particular duplicate expected input.

A forms module 248 may provide form design functionality with respect toforms to be used in the process for data collection or input. The formsmodule 248 may therefore provide a user the functionality to design aform layout and to define one or more data elements which are to becollected by means of the form. Such a form may, in some embodiments, bepresented in a GUI having one or more GUI elements, such as text boxesor the like, for receiving respective data inputs. Design of a form byway of the forms module 248 may thus include the association of each GUIelement with a respective data element. A form designed by means of theforms module 248 may be associated with a particular process activity atthe outset or after completion of designing the form. The duplicationidentifier module 220, as well as the alert generator 242, may cooperatewith the forms module 248 to provide design-time duplicationidentification and duplication alerts. A user may thus be alerted toduplication of expected input upon the association of a particular dataelement with a form (if the form has already been associated with aparticular process activity) or upon association of the form with one ofthe process activities.

Instead, or in addition, the process model application(s) 120 mayinclude a forms import/conversion module 244 to facilitate design offorms in applications which may not be integrated with the process modeland the subsequent importation of such forms into the process model. Auser may, for example, wish to design forms in an application such as MSVisio™ or MS Excel™ and thereafter to associate these forms withrespective process activities. The forms import/conversion module 244may serve to convert and import such forms, while facilitating expectedinput duplication identification by the duplication identifier module220 and the generation of a duplication alert by the alert generator242. Such form input/conversion may be performed in a batch process.

The process model application(s) 120 may further include a qualityanalyzer module 246 to analyze and/or enforce consistency in dataelement definition within the process model and its associated forms.The quality analyzer module 246 may, for example, compare a data elementdefined by a process designer or user in a form, or explicitlyassociated with a process activity, with a data enterprise model. Thedata enterprise model may comprise a list of data elements for use inthe process model and may therefore effectively function as a dictionaryfor data element definitions in the process model. The quality analyzermodule 246 may, in response to a failure to identify an exact match inthe data enterprise model for a user-provided data element, identifyalternative data elements based on semantic and/or phonetic similaritiesbetween the user-provided data element and the alternative dataelements. The quality analyzer module 246 may then suggest thealternative data elements to the user.

The process model application(s) 120 may further include a datagathering module 224 to gather and collate, at runtime, informationregarding the performance of respective processes and/or activities. Tothis end, the data gathering module 224 may cooperate with monitoringapplications (not shown) installed in each of the process servers 142,144 and/or client machines (not shown) forming part of the enterprisesystem 140. The system 102 may thus gather and record informationregarding activities performed by respective elements forming part ofthe enterprise system 140. A data event, such as data synchronization,data collation, or data transfer between two data repositories, may belogged or recorded, to facilitate tracking or monitoring of performanceof the associated business activities.

To this end, the application(s) 120 may include a process monitoringmodule 206 to monitor performance of the processes defined in theprocess model. Data gathered by the data gathering module 224 may thusautomatically be compared to process activities which are scheduledaccording to the process model, thereby to identify process eventfailures. The process monitoring module 206 may further compilehistorical data regarding system failures. Such historical data may, inparticular, include applications failure history, infrastructure failurehistory, physical infrastructure failure history, and the like. Anapplication failure may, for example, include failure of a processapplication to execute, while an infrastructure failure may compriseunscheduled downtime of a server or unavailability of communicationlinks between system components.

To facilitate process management, the process model application(s) 120may include a load projection module 212 to calculate a projected loadon particular processes and/or activities defined in the enterprisemodel. “Load” means the amount of work that is performed by a process ata particular point in time or over a particular period. The load on aparticular process or process activity may, for example, be calculatedas a number of cases scheduled to be processed. A “case” is an instanceof a process. For example, in a process for generating invoices, aparticular case may refer to a specific invoice generated for aparticular customer. Load projection may be calculated with respect to aparticular process step or activity, with respect to a specified processor sub-process, with respect to a process group, or with respect to theentirety of the enterprise model. The load projection module 212 may beconfigured to calculate the load projection based, in part, on currentload information, which may be gathered by the data gathering module224.

A process model analysis module 208 may provide for automated orcomputer-assisted analysis of the process by analysis of the processmodel. Analysis functionality provided by the process model analysismodule 208 may include analysis of the data collection efficiency of theprocess. To this end, the process model analysis module 208 may includean efficiency calculation module 230 to calculate a data collectionefficiency value based at least in part on duplicate expected inputsidentified by the duplication identifier module 220. The process modelanalysis module 208 may also provide the functionality of comparing thedata collection efficiency of an as-is process with that of a to-beprocess or comparing the data collection efficiency of separateprocesses.

Data Structures

FIG. 3 is an entity-relationship diagram, illustrating various memories,tables, data repositories, or databases that may be maintained withinthe database(s) 126 (FIG. 1), and that may be utilized by the processmodel application(s) 120. The database(s) 126 may include logicalprocess model information 310 representative of processes and activitiesperformed by the enterprise system 140. The logical process modelinformation 310 includes a logical process model 312 comprisingstructured data defining process activities included in the process andshowing relationships between respective process activities. In thecurrent example, the logical process model 312 may be a logical processmodel defining the sequence of process activities abstractly, withoutdefining the relationships of the activities or processes to processelements associated with operationalization of the process, which may beprovided by the dependency information 302. The logical process model312 references failure definitions 314 which may include SLAs 316 andKPIs 318. The failure definitions 314, SLAs 316, and KPIs 318 may beuser-specified via the rules engine 202 (FIG. 2).

The system 102 may include data input information 350 regarding aplurality of expected inputs associated with respective processactivities of the logical process model 312. Information regarding eachexpected input 352 may comprise a data element identifier 354,identifying a particular data element which is to be collected duringperformance of the process, together with a process activity identifier356, identifying an associated process activity of the logical processmodel 312 during which the particular data element is to be collected.It will be appreciated that although in the embodiment illustrated withreference to FIG. 3, the data input information 350 and the logicalprocess model information 310 are shown to be stored separately, witheach expected input 352 being linked to a particular process activity ofthe logical process model 312 by its associated process activityidentifier 356, different data structures may be employed in otherembodiments, such as, for example, storing data element identifiers 354in direct association with respective process activities in the logicalprocess model information 310, so that the data input information 350effectively forms part of the logical process model information 310.

Each expected input 352 may have associated therewith a source typeidentifier 360 to identify the particular type of source from which theassociated expected input 352 is to be collected during execution of theprocess. The source type identifier 360 may identify one of apredetermined plurality of source types, for example, identifying asource type selected from the group comprising an external organization,an internal organization, and a computer application/system.

The data input information 350 may further include a duplicationacceptance indicator 362 associated with each expected input 352. Theduplication acceptance indicator 362 may serve to indicate that a userhas accepted that the expected input 352 associated with the duplicationacceptance indicator 362 is a duplicate expected input 352. As isexplained in greater detail below, a user/designer may automatically bealerted, in response to generating an expected input 352 by associatinga data element with a process activity, to the fact that the newlygenerated expected input 352 is a duplicate expected input, and may beprompted to indicate whether or not the duplicate expected input is tobe accepted. In response to affirmative indication from theuser/designer, a duplication acceptance indicator 362 may be associatedwith the newly generated expected input 352.

The data input information 350 may further include a duplication reasonindicator 364 illustrating a reason for duplication of the associatedexpected input 352. The information represented by the duplicationreason indicator 364 may again be gathered from a user/designer upongeneration of the expected inputs 352. It will be appreciated thatintentional input duplication may be included in a process for a varietyof reasons. In one embodiment, a user may be prompted to select one of apredetermined list of duplication reasons, for example, from a drop downmenu. In such a case, the predetermined list of duplication reasons mayinclude a state change of data, validation from compliance/risk ofcorrectness perspective, requirement from a tracking perspective, and anupdate on existing data. The source type identifiers 360, theduplication acceptance indicators 362, and the duplication reasonindicators 364 may form part of metadata 358 associated with therespective expected inputs 352. In one embodiment, the entry of a sourcetype identifier 360 may be mandatory, in that the entry of a source typeidentifier 360 is a prerequisite for creating an expected input.

The data input information 350 may yet further include linked forms 366comprising a plurality of forms that may be used during execution of theprocess to collect information or inputs. Each linked form 366 maycomprise layout information indicating the visual layout of the form,together with information of the data elements that are to be collectedby means of the form. In instances where the form is to be presented ona GUI of a terminal or a computer, the linked form 366 may define aplurality of user interface elements forming part of the form, and mayassociate particular data elements that are to be collected withparticular user interface elements of the form. The data inputinformation may additionally include information indicating particularprocess activities of the logical process model 312 with whichrespective linked forms 366 are associated. It will be appreciated thatexpected inputs 352 can thus be created by explicitly associating dataelements or data element identifiers 354 with respective processactivities, or, instead, a user/designer may create forms which includeinformation indicating the data elements collected by the forms, and maythereafter associate such forms with respective process activities,thereby creating the linked forms 366. Association of a linked form 366with a particular process activity may automatically result in thecreation of one or more expected inputs 352, with each data element tobe collected by the form automatically being associated with therelevant process activity to which the form has been linked.

The process model application(s) 120 may also access an enterprise datamodel 370 that comprises a list of data elements in the system 102. Theenterprise data model 370 may therefore function effectively as a dataelement dictionary, to facilitate consistency in the use of data elementidentifiers 354. As described in greater detail below, semantic and/orphonetic similarity searches may automatically be conducted upon theentry by the user of a data element identifier, and alternative dataidentifiers from the enterprise data model 370 may be suggested to theuser if no exact match to the data element identifier 354 entered by theuser can be found in the enterprise data model 370. Information in theenterprise data model 370 may be arranged according to an entity towhich respective data element identifiers pertain. For example, addressinformation may be grouped together, so that data element identifiersfor an address line, a city address, a state identifier, a zip code, anda zip extension code may be grouped together under an “address” group.

The databases 126 may further may include dependency information 302comprising structured information regarding dependencies of respectiveprocesses and/or process activities of the enterprise model. Thedependency information 302 may include IT system dependency information304 that comprises information regarding process dependency on IT systemelements of the enterprise system 140. The IT system dependencyinformation 304 may thus include information regarding dependency ofprocesses or activities on software such as process applications 146,148, as well as dependency on IT infrastructure. The IT systemdependency information 304 also includes datastore dependencyinformation indicative of relationships between respective activitiesand datastores that are accessed in performance of the respectiveactivities. The IT system dependency information 304 enables thegeneration of an interactive GUI displaying those process applicationsand process servers on which a selected process or process activity isdependent.

The dependency information 302 may further include human resourcesdependency information 306 in which is stored structured informationregarding the dependency of respective processes or process activitieson particular human resource components, such as people or personnel.The HR dependency information 306 may, for example, specify the job roleor personnel department responsible for the performance of a particularprocess activity. Physical infrastructure dependency information 307 mayalso be included in the dependency information 302 to indicate thedependency of respective process activities on physical infrastructurecomponents. Such physical infrastructure components may include, forexample, vehicles, machinery, supply-chain elements, buildings, and thelike. Data dependency information 308 may illustrate the dependency ofprocess activities on data in the one or more datastores which may beaccessed in execution of respective activities.

The system 102 further comprises historical data 320 indicative of pastperformance of processes defined in the logical process model 312, aswell as being indicative of the latest state of process elements anddata in respective datastores. The historical data 320 may preferably begathered in real-time or near real-time, optionally being gathered uponperformance of the respective processes or process activities. Instead,or in combination, the historical data 320 may be gathered at predefinedtimes or intervals. Historical data 320 may include applications failurehistory 322 indicative of failure of process applications 146, 148, aswell as IT infrastructure failure history 324 indicative of pastfailures of IT infrastructure elements, such as process servers 142,144. The historical data 320 may further include physical infrastructurefailure history 327 with respect to failure of physical infrastructureelements, such as vehicles, machinery, and the like. Human resourceperformance history 323 may also form part of the historical data 320,to provide information regarding historical performance of particularhuman resource components such as personnel, personnel departments,operational units, and the like. The historical data 320 may furtherinclude data state information 326 indicative of the current or latestrecorded state of data in respective datastores of the enterprise system140. In some embodiments, the generation and storage of historical data320 may be omitted.

Scheduling information 340 may be provided to facilitate risk analysisor predictive analysis. The scheduling information may include:applications downtime schedules 342 indicating scheduled unavailabilityor downtime of process applications 146, 148; IT infrastructure downtimeschedules 344 indicating scheduled unavailability of IT infrastructureelements or components, such as process servers 142, 144; physicalinfrastructure schedules 345 indicating scheduled availability ofphysical infrastructure elements; and human resource schedules 346,which may include holiday calendars or personnel unavailabilityschedules, to indicate when personnel, people, or other human resourcecomponents supporting the process are scheduled for unavailability. Insome embodiments, the generation and storing of scheduling information340 may be omitted.

The databases 126 may furthermore include load information 370 regardinga current and a projected load on respective elements in the process. Inparticular, the load information 370 may include information onapplications load 372 indicative of current and projected load onprocess applications 146, 148; IT infrastructure load 374 indicative ofcurrent and projected loads on the IT infrastructure the enterprisesystem 140; physical infrastructure load 375 indicative of current andprojected loads on physical infrastructure elements; and informationregarding current and projected load on human resources 376. Provisionof the load information 370 facilitates analysis of the business processmodel, and may be particularly useful in load balancing managementanalysis, but in some embodiments, the generation and storing of loadinformation 370 may be omitted.

As illustrated in FIG. 3, the process model application(s) 120 mayaccess the logical process model information 310, the data inputinformation 350, the enterprise data model 370, the dependencyinformation 302, the historical data 320, the scheduling information340, and the load information 370 during process model creation/editingand/or during process analysis. In particular instances, the duplicationidentifier module 220, forming part of the process model application(s)120, may access the data input information 350 and the logical processmodel information 310 to identify duplicate expected inputs 352.

FIG. 4 is a high-level entity relationship diagram of an exampleconfiguration of a process model system 400. The system 400 may includea computer 402, which may include a duplication identifier module 220 toperform analysis on data input information 350 with respect to logicalprocess model information 310, to identify the duplicate expectedinputs. Like numerals indicate like elements in FIG. 3 and in FIG. 4.

The system 400 includes a number of databases or memories to store thelogical process model information 310 and the data input information350. It is to be noted that these databases are illustrated as separateentities, but that process model information can instead be stored in asingle database, or in a greater number of dispersed databases, whilethe process model information may be stored either internally in thecomputer 402 or may be stored externally. In this context, the termsdatabase and memory are to be understood as being equivalent.

GUIs

The concepts described above will now be further explained by way ofexample with reference to extracts from example GUIs that may begenerated by the GUI module 200, according to an example embodiment.FIG. 5 indicates an example graphical representation of a value chaindiagram 500 providing an overview of an example process defined by aprocess model, which may be an enterprise model. The value chainrepresents the chain of business activities that generate value for anenterprise. The example value chain diagram 500 is with respect to abusiness that provides credit card services to customers. The valuechain diagram 500 represents the highest level of the enterprise modeland comprises, at the highest level, a series of organizational units.In this example, the value chain diagram 500 comprises theorganizational units of Marketing 502; Customer Services, Operations andFinance/Accounting 504; Credit and Risk Management 506; and Collections508.

It is to be noted that, at the highest level of the value chain,different enterprises in a particular industry or field of business maybe somewhat similar. For example, all computer chip manufacturing firmsmay have a similar sequence of elements, such as fabrication. However,the enterprise model includes further levels, which indicate theorganization of the particular enterprise, and in such low levels theremay be great differences between respective enterprises in the samefield. The particular organization of an enterprise may be influenced bythe scale of operations, the history of the enterprise, and a variety ofother factors. For instance, two cable television (TV) companiesoperating in adjacent markets and offering near identical products maybe completely different in their organization at lower levels. In otherexamples, the value chain diagram may decompose the enterprise process,at a high level, according to business domains. In this regard,“business domain” is understood as a particular line of business. Forexample, in a financial services organization, domains can includeDeposits, Loans, Investments, and Insurance. Such domains can be furtherdecomposed in sub-domains. A business domain of Loans can, for instance,be comprised of Corporate and Personal sub-domains.

As illustrated in FIG. 5, the value chain diagram 500 specifies thefunctional decomposition of each of the organizational units 502 to 508in respective series of functions or processes. Thus, for example, theorganizational unit of customer services, operations andfinance/accounting 504 is comprised of a series of functions orprocesses. A user can view further organizational details or functionaldecomposition of each of the functional processes constituting theorganizational unit 504, by selecting the associated function or processin the GUI. Organizational units may thus be categorized by the functionthey perform. It is to be noted that functions may be specific to abusiness domain/sub-domain or may be shared across domains/sub-domains.For example, recruiting and other human resource functions may be sharedfunctions, while, for instance, warehouse operations may be specific toa sales and distribution area of a large retailer.

FIG. 6 indicates a functional decomposition diagram 600 of the functionof Transaction Processing and Management 510, specifying a series ofsub-functions which includes Dispute Management 610. The diagram 600 ofFIG. 6 is thus a lower-level view of one of the functions forming partof the diagram 500 of FIG. 5, and it will be appreciated that each ofthe functions shown in FIG. 5 may similarly be viewed at a lower-levelor in greater magnification.

Likewise, diagram 700 in FIG. 7 shows yet further functionaldecomposition of the sub-function of Dispute Management 610, whichcomprises a series of processes forming part of the Dispute Management610 sub-function. One of these processes is Monthly Billing ofPresentments and Re-Presentments 710. A user can select any one of theprocesses of FIG. 7 to view a process model specifying a series ofactivities comprising of the process, as well as dependency informationof the process activities. It is to be appreciated that decomposition ofa process into a series of process activities may be provided at thelevel of the enterprise model. In this example embodiment, aspectsrelating to the detection of wasteful data collection and theidentification of duplicate expected inputs will be further describedwith reference to a customer on-boarding process 520 referenced at ahigh level in FIG. 5.

FIG. 8 shows a suppliers, inputs, process, outputs, and customers(SIPOC) diagram 800 representative of such an example process model forthe process of customer on-boarding 520 (FIG. 5. It is to be appreciatedthat the user may thus drill down to a specific process model, asexemplified by the various levels of the enterprise model illustrated inFIGS. 4-7. The number of levels of the enterprise model may varydepending on the complexity of the enterprise.

The process 800 may include a logical process model indicating asequence of activities 802-814. Entities responsible for performance ofthe respective process activities are indicated in the diagram of FIG. 8by location of blocks representing the activities 802-814 in one of anumber of bands or “swim lanes” 830-842.

The customer on-boarding process is initiated by the provision of basiccustomer information 850, at block 802, by a customer 830. In thecurrent example, the basic information 850 comprises the following dataelements, with respective data element identifiers 354 provided inparenthesis: a customer name (Cust_Name), an organization with which thecustomer is associated (Cust_Org), a customer e-mail address(Cust_Email), a customer telephone number (Cust_Phone), and a customeraddress (Cust_Address). Each of the data elements comprising the basiccustomer information 850 is associated with the operation of providingcustomer information, at block 802, and is therefore an expected inputin the process 800.

This basic customer information 850 is used by a customer relationsmanagement system (CRM) 832 to update a billing system 836, at operation804. Such updating may comprise provision of the basic customerinformation 850 to the billing system 836 by the CRM system 832. Acustomer service representative (CSR) 838 may thereafter check, atoperation 808, whether or not the customer is an existing customer. Tothis end, the CSR 838 references an enterprise content management system(ECM) 842. If, at decision block 810, it is determined that the basiccustomer information 850 is with respect to a new customer, then the CSR838 performs the operation, at block 812, of creating a new customer inan underwriting system 840. The new customer is therefore created withreference to the basic customer information 850, which is provided tothe underwriting system 840 by the CSR 838. If, however, it isdetermined, at decision block 810, that the information is with respectto an existing customer, as would be indicated by the existence of acustomer record 854 for the particular customer in the ECM 842, then theCSR 838 performs the operations, at block 814, of updating the customerrecord in the ECM 842.

The process may include the provision of additional customer information852 with respect to the customer 830 by an agent 834. In the presentexample embodiment, the data elements provided as part of the additionalcustomer information 852 may comprise a customer telephone number(Cust_Phone), a customer e-mail (Cust_Email), an industry segment towhich the customer is active (Cust_Segment), and a customer's estimatedrevenue (Cust_Revenue). As can be seen in FIG. 8, the additionalcustomer information 852 provided by the agent 834 is consumed by theCRM system 832. After provision of the additional customer information852, the customer service representative 838 may again check, at block808, whether or not the customer has a record in the ECM 842. If acustomer record 854 has already been created, then the CSR 838 mayupdate the customer record 854, at operation 814.

Flowcharts

FIG. 9 illustrates, at a high level, a flowchart for a method 900 ofdetecting wasteful data collection in a process. The method comprisesassociating expected inputs with respective process activities, at block902, and thereafter automatically identifying duplicate expected inputs,at block 904. By automatically identifying duplicate expected inputs andbringing such duplicate expected inputs in a defined process, such asthat described with reference to FIG. 8, to the attention of a user whois designing the process, the process may be optimized to minimizewasteful data collection. Automatic identification of duplicate expectedinputs may also be used to assess data collection efficiency of aparticular process or part thereof.

A more detailed exemplary method will now be described with reference toFIG. 10, in which flowchart 1000 illustrates a sequence of operations inthe method. The example embodiment of FIG. 10 will be described withreference to an enterprise model system 102 of FIGS. 1-3, and withreference to the example process 800 of FIG. 8. First, a user (alsoreferred to herein as a designer or administrator) may design or editthe process 800, at block 1004, by use of the model building/editingmodule 204.

The building or editing of the process may include associating dataelements with respective process activities by use of the inputassociation module 240, at block 1008, to create expected inputs. Asused herein, an expected input means an indication of expectedcollection of a particular data element during execution of theassociated process activity. In the present example embodiment, the usermay provide a data element identifier 354 (FIG. 3) associated with therespective process activity, for each expected input. For example,expected collection of a customer name (Cust_Name) during provision ofcustomer information, at block 802 (FIG. 8), represents a singleexpected input. Table 1 below illustrates a list of the expected inputsassociated with the process 800 of FIG. 8.

Associating data elements with process activities may also includeproviding additional information regarding the type of source thatprovides each expected input. For example, the user may specify, withrespect to each expected input, whether the expected input is to beprovided by an external entity (identified by the source type identifier360 “External”), by a person internal to an organization responsible forexecuting the process (“Internal”), or by a system, such as the ECM 842or the CRM system 832 (“System”). In the present embodiment, the method1000 may enforce mandatory provision of a source type with respect toeach expected input. To this end, the user may be prompted, at block1010, to enter the source type of the relevant data element. The promptgenerated at block 1010 may include a drop down list from which the useris to select an appropriate source type, in order to proceed.

TABLE 1 Source Type No Process Activity Data Element ID ID 1 ProvideCustomer Info Cust_Name External 2 Provide Customer Info Cust_OrgExternal 3 Provide Customer Info Cust_Email External 4 Provide CustomerInfo Cust_Phone External 5 Provide Customer Info Cust_Address External 6Update Billing System Cust_Name System 7 Update Billing System Cust_OrgSystem 8 Update Billing System Cust_Email System 9 Update Billing SystemCust_Phone System 10 Update Billing System Cust_Address System 11Provide Additional Customer Info Cust_Phone External 12 ProvideAdditional Customer Info Cust_Email External 13 Provide AdditionalCustomer Info Cust_Segment External 14 Provide Additional Customer InfoCust_Revenue External 15 Create Customer in UW System Cust_SegmentInternal 16 Create Customer in UW System Cust_Name Internal 17 CreateCustomer in UW System Cust_Email Internal 18 Create Customer in UWSystem Cust_Phone Internal 19 Create Customer in UW System Cust_AddressInternal 20 Create Customer in UW System Cust_Revenue Internal 21 UpdateECM System Cust_Revenue Internal

Upon association of a particular data element with a process activity,at block 1008, the quality analyzer module 246 automatically analyzes,at block 1012, the particular data elements, with reference to theenterprise data model 370, to assess whether or not the data elementidentifiers 354 are consistent with the enterprise data model 370. If noexact match to the source type identifier 360 is found in the enterprisedata model 370, then the quality analyzer module 246 may perform aphonetic and/or semantic similarity search through the enterprise datamodel 370, and may suggest to the user, at block 1016, a list ofalternative data element identifiers 354 that are already included inthe enterprise data model 370. The user may either accept, or reject, atblock 1020, the suggested alternative data element identifiers. If theuser accepts a suggested alternative data element identifier, theduplication identifier module 220 automatically analyzes the data inputinformation 350 (FIG. 3), at block 1024, based on the accepted dataelement identifier 354, to determine whether or not the expected inputis a duplicate expected input. If a user rejects, at block 1020, thesuggested alternative data element identifiers from the enterprise datamodel 370, or if there is an exact match for the user-entered dataelement identifier 354, then the operation of identifying duplicateexpected inputs, at block 1024, is performed with reference to theuser-entered data element identifier 354.

The identification of duplicate expected inputs, at block 1024,comprises determining whether or not the data input information 350already includes an expected input 352 with respect to the particulardata element identifier 354. Thus, for example, if the user first entersthe expected inputs with respect to the operation of providing customerinformation (represented by block 802 in FIG. 8), and thereafterassociates the data element relating to a customer telephone number(Cust_Phone) with the operation of providing additional customerinformation (represented by block 806 in FIG. 8), the duplicationidentifier module 220 will determine that the data element identifier“Cust_Phone” is already associated with another process activity, andthat the expected input 352 which the user is attempting to create istherefore a duplicate expected input. In other words, the dataduplication identifier module 220 determines that there is at least oneother expected input 352 with respect to a common corresponding dataelement (Cust_Phone). In some embodiments, a duplicate expected inputwill only be identified if the respective expected inputs 352 relatingto the common data element are associated with different processactivities. In other embodiments, duplicate expected inputs may also beidentified in instances where a particular data element is associatedmore than once with the same process activity.

In response to identification of a duplicate expected input 352, atblock 1024, the alert generator 242 automatically raises a duplicationalert, at block 1028. The user is prompted by the duplication alert toaccept or reject the identified duplicate expected input, at block 1032.If the duplicate expected input is rejected, the user may edit orredesign the process, or may select a different data element forassociation with the relevant process activity, at block 1008. In theexample process 800 of FIG. 8, the collection of the data elementCust_Email in the provision of additional customer information, at block806, may be omitted, for example by changing an associated form toremove collection of the customer e-mail therefrom.

If, however, the user accepts the identified duplicate expected input,the duplicate expected input is recorded as part of the data inputinformation 350. However, a duplication acceptance indicator 362 (FIG.3) is stored in the data input information 350 in association with theduplicate expected input, indicating that the user/designer has acceptedduplication of the particular expected input. The raising of duplicationalerts, at block 1028, may in some embodiments be limited to identifiedduplicate expected inputs obtained from an external source.

The user may also be prompted, at block 1036, to provide a reason forduplication of an expected input. In a particular embodiment, the usermay be presented in a GUI with a predetermined list of reasons forduplication of expected inputs. Such reasons may include to trackchanges in the state of data, to validate data from a compliance/riskperspective, that duplication is a requirement from a trackingperspective, and to update existing data. In response to provision ofthe reason for duplication, at block 1036, a duplication reasonindicator 364 reflecting the user input in this regard, together withthe duplication acceptance indicator 362 and a source type identifier360, may be associated, at block 1040, with the newly created expectedinput 352 as metadata 358 in the data input information 350 of thesystem 102. The operations represented by blocks 1012 through 1040 maybe repeated for each data element associated by the user with arespective process activity.

Instead of, or in addition to, explicit association of individual dataelements with respective process activities, at block 1008, theassociation of particular data elements with process activities, toreflect expected inputs, may be effected through the creation or editingof forms which are associated with process activities. To this end, theforms module 248 provides a functionality whereby a form may beassociated with a particular process activity, at block 1060, whereafterform layout and content may be defined, at block 1064, and data elementsmay be associated with the form, at block 1068. The forms module 248 mayprovide interactive functionality, so that upon association of aparticular data element with the form, data quality analysis may beperformed by the quality analyzer module 246 and expected inputduplication may be identified by the duplication identifier module 220.The operations represented by blocks 1012 through 1040 in FIG. 10 maythus be repeated for each data element that is associated with one ofthe process activities, at block 1068.

A further alternative method of creating expected inputs may comprisethe preparation of forms in a computer application which is notcompliant with the duplication identifier module 220. A user may thusgenerate forms, at block 1070, in an application such as MS Word™, MSExcel™, or MS Visio™, and may thereafter import such forms, at block1074, by use of a forms import/conversion module 244. In someembodiments, the forms import/conversion module 244 is configured topermit batch import of a plurality of forms that may have been createdin the noncompliant applications. When such a noncompliant form isimported by the system 102 and is converted to be compliant with thelogical process model information 310 and data input information 350,operations 1012 through 1040 may be performed with respect to each dataelement or data element identifier included by the user in the form.

In FIG. 11, a flowchart 1100 is shown, representing an exemplaryembodiment of a method for analyzing the data input information 350 toassess data collection efficiency of a process or part thereof. First, auser selects, at block 1104, a process or a part of a process forconsideration, in order to calculate a data collection efficiency valuefor the selected process or part thereof. Thereafter, process analysisis performed, at block 1108, by the process model analysis module 208.

The process analysis comprises, at block 1112, identifying duplicateexpected inputs forming part of the data input information 350associated with the selected process. The identification of duplicateexpected inputs is effected by the duplication identifier module 220 andis similar or analogous to the operation performed with reference toblock 1024 in FIG. 10, as described above. The identification ofduplicate expected inputs, at block 1112, with reference to the exampleprocess 800 described with reference to FIG. 8 and Table 1, may returnresults of such as that contained in Table 2 below.

TABLE 2 Data Data Source Element ID Process Activity Provider TypeSystem Cust_Email Provide Customer Info Customer External CRM Cust_PhoneProvide Customer Info Customer External CRM Cust_Phone ProvideAdditional Agent External CRM Customer Info Cust_Email ProvideAdditional Agent External CRM Customer Info Cust_Revenue ProvideAdditional Agent External CRM Customer Info Cust_Revenue Update ECMSystem CSR Internal ECM

The process analysis 1108 may further include, at block 1120,identifying a source type for each duplicate expected input, based, forexample, on the associated source type identifiers 360. Duplicationweights may thereafter be allocated to each of the identified expectedduplicate inputs, at block 1124. In an example embodiment, a relativelyhigh duplication weight may be allocated to all duplicate expectedinputs that are provided by entities external to the process system 102.Duplicate inputs that are received from, for example, customers andexternal organizations may therefore be provided with a relatively highduplication weight. It will be appreciated in this regard that moresevere data quality issues may be caused by inaccurate or inconsistentdata input, and that the likelihood of such inaccurate or inconsistentdata input being received from external entities is greater than thelikelihood of inaccurate data inputs being provided by internalentities. Additionally, duplicate inputs required from external agentsmay be frustrating to such entities, and unnecessary input duplicationmay result in reduced custom or agent satisfaction and increasedbusiness impact. A medium weight may be applied to duplicate expectedinputs, which are provided by an internal entity, such as employees oragents of a company or organization executing the process 800. Theinternal entities to which a medium duplication weight may be appliedare human actors or internal organizations, as opposed to computersystems or applications. Expected duplicate inputs that are provided byinternal applications or computer systems may be provided a lowestduplication weight. In the present example embodiment, expectedduplicate inputs from an external source maybe allocated a weight valueof 3, while expected duplicate inputs from internal sources may beallocated a weight value of 2, and expected duplicate inputs fromcomputer applications or systems may be allocated a weight value of 1.Table 3 shows application of the above-described weightage method to theexample process of FIG. 8.

Following the allocation of duplication weights, at block 1124, anefficiency value calculation may be performed, at block 1128. In thepresent example embodiment, the efficiency value calculation comprisesdivision by the total number of data elements that are to be collectedin the analyzed process 800 of the cumulative duplication weight valuesfor the processor 800. In other words, the allocated duplication weightsfor the duplicate expected inputs are summed, and the cumulative valueof duplication weights is thereafter divided by the count of dataelements that are to be collected in the process 800. With reference toTable 3, it will be seen in that the total of allocated duplicationweight values for the process 800 is 8, while the number of dataelements to be collected in the process is 7 (as can be seen withreference to Table 1, which includes 7 unique data element identifiers).The efficiency value calculation, at block 1128, will therefore, withreference to the example process of FIG. 8, return a data collectionefficiency value of 1.14, which may be outputted on a graphical userinterface, at block 1132. It will be appreciated that a higher datacollection efficiency value indicates lower data collection efficiencyor more wasteful data collection, while a data collection efficiencyvalue of 0 would indicate no inefficiency in data collection.

TABLE 3 Source Duplicate Weight/ Duplication Data Source Type CountDuplicate Weight Cust_Phone Agent External 1 3 3 Cust_Email AgentExternal 1 3 3 Cust_Revenue CSR Internal 1 2 2 Total 8

The calculation of a data collection quality ratio or data collectionefficiency value as described above may be used to provide an indicationof the data collection efficiency of a process in isolation and/or maybe used for comparing the data collection deficiencies of two or moreprocesses. The process analysis 1108 may, for example, be used tocompare the data collection efficiency of an as-is process with a to-beprocess, in order to assess the effect of possible changes to a processon the data collection efficiency of the process. A user may thus, atblock 1140, generate a to-be process after having obtained a datacollection efficiency value for a process in its current form. Thegeneration of the to-be process may typically comprise the addition,operation, or deletion of process activities, a change in the sequenceof process activities, and/or the combination of two or more existingprocesses. Data input conflicts in the to-be process may automaticallybe identified, at block 1142, and may be brought to the attention of theuser by the raising of a conflict alert, at block 1146. The processmodel analysis module 208 may thus, for example, identify when theoriginal collection of a particular data element is omitted. Processredesign may, for example, inadvertently omit a process activity inwhich a particular data element is originally collected, which wouldnegatively affect downstream processes that consume that particular dataelement. A user may, in response to such a conflict alert, reinstate theomitted process activity, or may include collection of the particulardata element in another process activity.

In addition to automatic identification of data element conflicts, theprocess model analysis module 208 may identify a list of data elementsthat may be affected by a particular change in the process or in a formassociated with the process. The user may thus indicate a particularchange and may request a list of data elements affected by the change.Such analysis may also be performed in order to identify a list ofsystems and databases utilizing potentially conflicting data, and mayanalyze the impact of a change to the process and/or forms in thisregard. For example, if a user contemplates the removal from the process800 of FIG. 8 of collection by the agent 834 of the data elementCust_Email, then the process model analysis module 208 may provide theuser with a list of system elements and forms that use that dataelement.

The process model analysis module 208 may also be utilized to facilitateprocess optimization, by analyzing and reporting to a user detailsregarding the use by the process and process elements of particular dataelements. A user may, for example, select the data element or data fieldCust_Email for analysis with respect to the processor 800 of FIG. 8. Inresponse to such a request, the process model analysis module 208 mayprovide the following information for the data field Cust_Email:

“Cust_Email”

1. Input into CRM system 1 time.

2. Output by CRM system 2 times.

3. Referenced by billing system 1 time.

4. Input by external user 2 times.

This information may be used to redesign or edit the process in order toimprove data collection efficiency.

In another embodiment, the data input information 350 may be analyzed todetermine a significant or critical source (or so-called golden source)for a particular data element, and a conflict alert may be raised ifcollection of a data element from its critical source is deleted oromitted in the to-be process. Instead, or in addition, the method mayinclude analyzing the data input information 350 to assess or determinethe importance of respective data elements that are to be collected inexecution of the process. The importance of a particular data elementmay be determined based on the number of times the particular dataelement forms part of an expected input, based on the user-providing areason for expected input duplication, and/or based on the source typeof respective duplicate expected inputs with respect to the particulardata element. In this regard, greater repetition of collection of aparticular data element tends to indicate greater importance of thatdata element. A conflict alert may be raised, at block 1146, if a uniqueexpected input from a particular source is, for example, deleted orremoved in generation of the to-be process, at block 1140.

The above described method of detecting wasteful data collection may beof particular use in the combination of existing processes, for examplein the instance of the merger of two corporate entities. In such cases,repetitive collection of data elements in extensive combined processesmay be difficult to detect and/or streamline. The above-describedexample embodiment, however, facilitates efficient data collection insuch processes initially by automatically detecting duplicate expectedinputs during process design/editing, and secondly by providing thefunctionality for calculating a data collection efficiency value for oneor more processes. A method is thereby provided to define therelationship of data elements with processes forming part of anenterprise process model, and may link the data elements to anenterprise data model, to facilitate the identification of wasteful datacollection.

An enterprise data model may also automatically be generated ininstances where an enterprise does not yet have an enterprise datamodel. In such cases, an enterprise data model may automatically begenerated upon the association of data elements with respective processactivities, whereafter consistency with the previously entered dataelements may be enforced, as described above.

FIG. 12 shows a diagrammatic representation of machine in the exampleform of a computer system 1200 within which a set of instructions, forcausing the machine to perform any one or more of the methodologiesdiscussed herein, may be executed. In alternative embodiments, themachine operates as a standalone device or may be connected (e.g.,networked) to other machines. In a networked deployment, the machine mayoperate in the capacity of a server or a client machine in server-clientnetwork environment, or as a peer machine in a peer-to-peer (ordistributed) network environment. The machine may be a server computer,a client computer, a personal computer (PC), a tablet PC, a set-top box(STB), a Personal Digital Assistant (PDA), a cellular telephone, a webappliance, a network router, switch or bridge, or any machine capable ofexecuting a set of instructions (sequential or otherwise) that specifyactions to be taken by that machine. Further, while only a singlemachine is illustrated, the term “machine” shall also be taken toinclude any collection of machines that individually or jointly executea set (or multiple sets) of instructions to perform any one or more ofthe methodologies discussed herein.

The example computer system 1200 includes a processor 1202 (e.g., acentral processing unit (CPU) a graphics processing unit (GPU) or both),a main memory 1204 and a static memory 1206, which communicate with eachother via a bus 1208. The computer system 1200 may further include avideo display unit 1210 (e.g., a liquid crystal display (LCD) or acathode ray tube (CRT)). The computer system 1200 also includes analphanumeric input device 1212 (e.g., a keyboard), a cursor controldevice 1214 (e.g., a mouse), a disk drive unit 1216, a signal generationdevice 1218 (e.g., a speaker) and a network interface device 1220.

The disk drive unit 1216 includes a machine-readable medium 1222 onwhich is stored one or more sets of instructions (e.g., software 1224)embodying any one or more of the methodologies or functions describedherein. The software 1224 may also reside, completely or at leastpartially, within the main memory 1204 and/or within the processor 1202during execution thereof by the computer system 1200, the main memory1204 and the processor 1202 also constituting machine-readable media.

The software 1224 may further be transmitted or received over a network1226 via the network interface device 1220.

While the machine-readable medium 1222 is shown in an example embodimentto be a single medium, the term “machine-readable medium” should betaken to include a single medium or multiple media (e.g., a centralizedor distributed database, and/or associated caches and servers) thatstore the one or more sets of instructions. The term “machine-readablemedium” shall also be taken to include any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by themachine and that cause the machine to perform any one or more of themethodologies described herein. The term “machine-readable medium” shallaccordingly be taken to include, but not be limited to, solid-statememories, optical and magnetic media, and carrier wave signals.

Thus, a method and system to perform an analysis of a process supportedby a process system have been described. Although the methods andsystems described herein have been exemplified with reference tospecific example embodiments, it will be evident that variousmodifications and changes may be made to these embodiments withoutdeparting from the broader spirit and scope of method and/or system.Accordingly, the specification and drawings are to be regarded in anillustrative rather than a restrictive sense.

The Abstract of the Disclosure is provided to comply with 37 C.F.R.§1.72(b), requiring an abstract that will allow the reader to quicklyascertain the nature of the technical disclosure. It is submitted withthe understanding that it will not be used to interpret or limit thescope or meaning of the claims. In addition, in the foregoing DetailedDescription, it can be seen that various features are grouped togetherin a single embodiment for the purpose of streamlining the disclosure.This method of disclosure is not to be interpreted as reflecting anintention that the claimed embodiments require more features than areexpressly recited in each claim. Rather, as the following claimsreflect, inventive subject matter lies in less than all features of asingle disclosed embodiment. Thus the following claims are herebyincorporated into the Detailed Description, with each claim standing onits own as a separate embodiment.

What is claimed is:
 1. A system comprising: at least one database tostore logical process model information defining a logically structuredseries of process activities in a process, and data input informationrepresenting a plurality of expected inputs associated with respectiveprocess activities of the series of process activities, each expectedinput being indicative of expected collection of a corresponding dataelement during execution the associated process activity; and a computerincluding a duplication identifier module to analyze the data inputinformation to automatically identify duplicate expected inputs, eachduplicate expected input being one of the plurality of expected inputsfor which there is at least one other expected input with respect to acommon corresponding data element, the duplicate expected input and theat least one other expected input being associated with differentprocess activities.
 2. The system of claim 1, further comprising anefficiency calculation module configured to calculate a data collectionefficiency value based at least in part on the identified duplicateexpected inputs.
 3. The system of claim 2, wherein the data inputinformation includes a source type identifier associated with eachexpected input to indicate a particular one of a predefined plurality oftypes of sources from which the associated expected input is to bereceived, the efficiency calculation module configured to allocate aduplication weight to each duplicate expected input corresponding to itsassociated source type identifier.
 4. The system of claim 3, wherein thedata input information further comprises a duplication acceptanceindicator associated with at least one duplicate expected input toindicate that the at least one duplicate expected input isuser-accepted, the efficiency calculation module configured to regardthe user-accepted duplicate expected input as a non-duplicate expectedinput in calculation of the data collection efficiency value.
 5. Thesystem of claim 3, wherein the data input information further comprises,associated with each user-accepted duplicate expected input, metadataregarding a user-provided reason for expected input duplication.
 6. Thesystem of claim 3, further comprising an input association module topermit user creation of expected inputs and to enable selectiveassociation by a user of the expected inputs with process activitiesforming part of the logical process model information.
 7. The system ofclaim 6, wherein the input association module includes an alertgenerator to automatically generate a duplication alert in response toidentification of expected input duplication, the duplication alertbeing generated upon association by the user of a particular duplicateexpected input with one of the process activities.
 8. The system ofclaim 7, wherein the duplication alert is to prompt the user to acceptthe particular duplicate expected input, and/or to prompt the user toprovide a reason for the particular duplicate expected input.
 9. Thesystem of claim 6, wherein the input association module comprises aforms module to permit user-association of a particular expected inputwith a form that is to be completed during execution of the process, theforms module further permitting user-association of the form with aselected process activity.
 10. A method comprising: associating aplurality of expected inputs with respective process activities of alogical process model comprising a logically structured series ofprocess activities in a process to be performed by a process system,each expected input being indicative of collection of a correspondingdata element during execution of the associated process activity; andusing one or more processors, analyzing expected inputs associated withtwo or more of the process activities, to automatically identifyduplicate expected inputs associated with the logical process model,each duplicate expected input being one of the plurality of expectedinputs for which there is at least one other expected input with respectto a common corresponding data element, the duplicate expected input andthe at least one other expected input being associated with differentprocess activities.
 11. The method of claim 10, further comprisingcalculating a data collection efficiency value based at least in part onthe identified duplicate expected inputs.
 12. The method of claim 11,further comprising associating with each expected input a source typeidentifier to identify a particular one of a predefined plurality oftypes of sources from which the expected input is to be received, thecalculation of the data collection efficiency value including allocatinga duplication weight to each duplicate expected input corresponding toits associated source type identifier.
 13. The method of claim 10,further comprising identifying user-accepted duplicate expected inputs,calculation of the data collection efficiency value comprising regardingthe user-accepted duplicate expected inputs as non-duplicate expectedinputs.
 14. The method of claim 10, further comprising associating witheach user-accepted duplicate input metadata regarding a user-providedreason for expected input duplication.
 15. The method of claim 10,further comprising automatically generating a duplication alert inresponse to identification of expected input duplication, theduplication alert being generated upon association by a user of aparticular duplicate expected input with one of the process activitiesduring an operation of mapping expected inputs to the processactivities.
 16. The method of claim 15, wherein generating theduplication alert includes prompting a user to accept the particularduplicate expected input, and/or prompting the user to provide a reasonfor the particular duplicate expected input.
 17. The method of claim 10,wherein associating a particular expected input with a selected processactivity comprises associating the particular expected input with a formthat is to be completed during execution of the process, and associatingthe form with the selected process activity.
 18. A non-transitorymachine-readable storage medium storing instructions which, whenperformed by a machine, cause the machine to: associate a plurality ofexpected inputs with respective process activities of a logical processmodel comprising a logically structured series of process activities ina process to be performed by a process system, each expected input beingindicative of collection of a corresponding data element duringexecution of the associated process activity; and analyze expectedinputs associated with two or more of the process activities, toautomatically identify duplicate expected inputs associated with thelogical process model, each duplicate expected input being one of theplurality of expected inputs for which there is at least one otherexpected input with respect to a common corresponding data element, theduplicate expected input and the at least one other expected input beingassociated with different process activities.